feat(wallet): Safe multi-owner accounts - #160

Freedom had no find-in-page. Add a Chrome-style overlay bar anchored to
the top-right of the webview area, driving the active tab's <webview>
via findInPage()/stopFindInPage() with match counts read back from the
found-in-page event.

- Cmd/Ctrl+F opens and focuses the bar (Edit-menu accelerator when the
  page has focus, renderer keydown fallback when the chrome does);
  prefills from the page's text selection when present
- Find-as-you-type (debounced), Enter / Shift+Enter cycle matches, Esc
  closes and clears highlights; zero matches shows "0/0" with a subtle
  error tint on the input
- Find state follows the foreground page: switching tabs closes the bar
  and clears the outgoing tab's highlights, navigating the active tab
  resets results while keeping the query for re-search on Enter
- New find:open IPC channel (main -> renderer) behind an explicit Edit
  menu item so the shortcut is discoverable; macOS keeps the editMenu
  role with a spelled-out submenu to append the item
- Dark/light theme support via the existing CSS variables

Tests: jest unit coverage for the find-bar state machine (mocked
webview) plus a Playwright harness spec covering match cycling, zero
matches, and tab-switch close.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Reverts 73ee4a0, which was pushed to main by accident (local
push.default=upstream resolved a bare-name push through the feature
branch's origin/main tracking ref). The feature re-lands through a
reviewed PR from feature/find-in-page.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

A Safe account has no key of its own: its owners are existing wallet
records, and a SafeTx is EIP-712 typed data, so every signer backend
(vault, Ledger, phone) co-signs through the ordinary getSigner seam.
src/main/wallet/safe/safe-executor.js orchestrates the rest over
@safe-global/protocol-kit (local SDK only — never the hosted Safe
Transaction Service): counterfactual address prediction, deployment
through the canonical safe-deployments factory (asserted, never a
user-supplied one), SafeTx build/hash returning plain-JSON shapes,
sequential recover-verified owner-signature collection, and
execTransaction submitted by an executor EOA that pays the gas.

The record's original init params (owners, threshold, saltNonce) are
the reproducibility anchor: buildSafeTransaction re-derives the CREATE2
address from them and refuses on mismatch, and the anvil-fork
integration test (skips without anvil/network) proves the same params
deploy to the same address on forked Gnosis AND Base, with retroactive
deployment claiming funds sent to the address before it existed.

getSigner(safeIndex) now throws — a Safe is an account, not a signer.
provider-manager grows getEip1193Provider(chainId) (protocol-kit needs
a raw request interface FallbackProvider cannot give) sharing the RPC
pool and cache invalidation; transaction-service grows toFeeFields so
callers stop re-deriving the eip1559/legacy branch.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

A Safe is now a first-class wallet record (type 'safe') whose owners
are existing accounts, created from the account dropdown with the two
shipped presets — backup (1 of 2) and resilient (2 of 3); 2-of-2 is
deliberately not offered since losing either device would brick the
funds. The record freezes the init params (owners, threshold,
saltNonce) that make the CREATE2 address reproducible; identity-manager
enforces the presets, refuses Safes owning Safes, and blocks deleting
an account while a Safe references it as owner.

Creation is free: safe-service predicts the counterfactual address and
stores the record, so the account can receive immediately. "Needs
funds" is a first-class blocking state, not an error — the status card
under Send/Receive quotes the one-time Gnosis activation (deployment
tx built once, gas + executor balance checked in parallel) and either
offers Activate, or blocks with "fund <executor> with ≥ X xDAI", or
explains that no owner can pay. Activation reuses the quoted
deployment tx, waits for confirmation, and only then marks the record
deployed (chain state also self-heals the record).

Until the multi-owner signing flow ships, Safe accounts are
receive-only: Send is disabled with an explanation and dApp connect
skips them (EIP-1271 comes later). The shared account picker grew
label/multi-select support so the owner list, Ledger, and phone
screens render from one component.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…ence

A deployed Safe can now send: the send flow branches into a Safe path
where main builds the SafeTx, collects owner signatures one device at a
time (vault instantly, Ledger tap, phone QR — all through the existing
signer seam), and submits execTransaction through the executor EOA. The
pending view shows a per-owner signature checklist driven by progress
events streamed from main; the review screen names who pays the fee
instead of quoting gas that can only be known after signing.

Every collected signature is persisted the moment it exists (interim
JSON, one pending SafeTx per Safe — a single slot sidesteps the nonce
replacement swamp). A rejection, an unreachable phone, a failed
broadcast, or an app restart never loses signatures: the status card
shows "transaction awaiting signatures (1 of 2)" with continue/discard,
and resume skips owners who already signed.

Safe transactions land in payment history: safe-send rows say from =
safe address with the executor and safeTxHash in metadata (tx-recorder
gained a fromAddress override), and activation deploys record as
safe-deploy. The payments page knows both kinds.

Also fixes a stale-capability bug: the renderer's record snapshot now
syncs deployment truth from main when the status card refreshes, so the
Send button enables right after activation instead of after a restart.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

startSafeSend passed the safe record straight into the executor layer,
so protocol-kit received the owners as wallet INDEXES and viem died on
getAddress(0) ("Address \"0\" is invalid") the moment a safe send was
confirmed. The activation path resolved them correctly; the send
orchestrator now does the same, and initPredictedKit fails loudly on
non-address owners so the index/address mixup can never reach the
address parser again.

The unit test had asserted the wrong shape against a mocked builder —
fixed, and the anvil-fork suite gained an un-mocked regression test
that walks the real record → build → collect(2/3) → execTransaction
path and checks the funds arrive.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

New Playwright spec drives the actual app end to end: create a 1-of-2
Safe in the wizard, hit the needs-funds blocking state, fund the
executor on an anvil fork of Gnosis (the registry's user config points
every Gnosis RPC at it, builtin endpoints removed), activate through
the canonical factory, watch Send enable, and send 0.5 xDAI out of the
Safe — recipient balance verified on-chain. Skips cleanly without
anvil/network, like the jest fork suite. The fork runs with
--block-time so confirmation behaves like the real chain.

Two findings it caught immediately, both fixed:
- activating with a locked vault failed silently to the console and
  reset the button — the status card now surfaces the error inline;
- the Safe send path skipped gas estimation and with it the only check
  that an asset was selected — validateAmount now owns that check.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Field testing a 2/3 Safe showed the flaw: signature collection ran as a
pipeline that marched through owners in record order and declared
"Transaction Failed" the moment the Ledger wasn't plugged in — for a
task that is fundamentally asynchronous and belongs to the user, not
the app.

Collecting signatures is now a board the user drives. Confirming a send
creates and persists the SafeTx, silently adds the free signatures
(mnemonic owners, vault unlocked — kept, that's what made 1-of-2 feel
instant), and opens a dedicated "Collect signatures" subscreen: what is
being sent and to whom, "1 of 2 signatures — any 2 of the 3 owners can
sign", when it started, and one row per owner with its own action
(Sign with Ledger / Show QR code) that the user taps when the device is
actually in hand. A failed attempt is a row state with main's error
message; a rejection is a decision — the row quietly returns to
waiting. The board is leaveable: the account card shows what's waiting
("Sending 0.5 xDAI to 0x12…cd — 1 of 2 signatures, started 2 days
ago") and re-opens it. While the board is open, an unplugged Ledger row
flips to "Ledger detected — sign now" the moment it's connected. The
phone QR overlay now says it's approving your own multi-owner
transaction instead of dApp copy.

Main's API turned granular and defensive: start (build + free
signatures only — devices are never cold-called), sign-one-owner
(per-safe mutual exclusion; a signature landing after its transaction
was discarded is dropped by a safeTxHash identity check), and execute
as its own idempotent step — auto-run by the board at threshold,
nonce-guarded so a broadcast that secretly landed (or an
app.safe.global execution) flips the transaction to a truthful terminal
"superseded" state instead of retry-looping, with an executor-can't-pay
banner and signatures that survive every failure. The progress event
stream is gone; the board renders from returned state.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Pending SafeTxs move out of the account status card into a wallet-wide
"Unfinished transactions" row above Recent payments, with a count badge
across ALL Safe accounts. It opens an overview subscreen (one entry per
waiting transaction: summary, which Safe, signature progress, age) and
each entry opens its signing board — with a single pending transaction
the row jumps straight to the board. The status card is back to
activation states only.

Also fixes the raw-wei summary ("Sending 2000000000000000 to …") that
pending transactions created before the presentation fields existed
rendered with: the summary now formats atomic amounts with the stored
decimals and falls back to xDAI for native sends.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Field report: tapping "Show QR code" on the signing board failed within
a split second with "Phone signing failed. Try again." A new E2E — a
phone owner co-signing a 2/3 SafeTx through the real bridge page over a
local relay — passes, which isolated the failure to the environment:
the default signaling relay (test.mosquitto.org's public TEST broker)
currently accepts TLS and instantly hangs up the MQTT websocket,
reproducible with a raw probe.

The session broker now resolves its relay per session: an explicit
override (env) is used as-is, otherwise the public candidates
(mosquitto, EMQX, HiveMQ) are probed with a single websocket handshake
and the first reachable one wins (cached for a minute). The chosen
relay rides inside the QR, so the phone always joins the same one —
and relays only ever carry ciphertext. Non-Error job failures also stop
collapsing into the generic registry message, so the next environmental
failure names itself.

The new safe-phone E2E stays: it covers the signing board's QR row end
to end (vault free signature + phone co-signature + execution, funds
verified on the fork).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Field report: after collecting both signatures the board said "Vault is
locked / The signatures are kept — you can try again" — the vault had
auto-locked while the phone signature was being gathered, and executing
needs the executor's vault key. A locked vault is a step in the flow,
not an error: the safe IPC handlers now tag vault-locked failures with
a stable code, and the signing board (execute AND per-owner sign) plus
the activation card respond by opening the standard vault-unlock
screen and retrying the step after a successful unlock. Cancelling the
unlock leaves an actionable notice instead of a dead end.

The safe-accounts E2E now exercises this path for real: it clicks
Activate with a locked vault, unlocks through the UI, and waits on the
Send button (the deployed-truth barrier — the status card sits inside
the identity view, which the unlock screen hides, so a card-hidden
assertion passes prematurely). The phone E2E tolerates the card
quoting before or after the executor funding lands.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

A dApp's personal_sign / eth_signTypedData_v4 against a Safe account is
answered with owner signatures over the SafeMessage EIP-712 envelope;
completeSafeMessage returns the sorted concatenated bytes the dApp
verifies via isValidSignature on the Safe.

- safe/safe-messages.js: in-memory sessions (a dApp request is a live
  promise that dies with its page); same-hash restart resumes with the
  collected signatures, a different hash replaces the dead session.
  Digests are computed with ethers over normalized input — protocol-kit's
  hashSafeMessage would UTF-8-hash hex personal_sign payloads, diverging
  from what EOA signers and verifying dApps compute.
- safe/signature-collection.js: the owner-collection machinery (in-flight
  lock, free-signature sweep, per-owner ceremony with identity re-check)
  extracted from safe-transactions over a store adapter; sends and
  message sessions share one lock per Safe.
- safe/errors.js: the SAFE_* code registry.
- IPC wallet:safe-message-start/-sign/-state/-cancel/-complete (lazy,
  VAULT_LOCKED-tagged) + window.wallet.safeMessage*.
- Fork test: collected signatures pass isValidSignature(bytes32,bytes)
  on the real deployed contract for personal_sign AND typed data; a
  tampered digest is refused.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

- dapp-connect lists DEPLOYED safes (receive-only stay hidden), defaults
  to the active account, and says upfront that a multi-owner account
  signs as a smart contract some apps can't verify (same caveat on the
  sign approval screen).
- Message signing routes through the signing board's new 'message' mode:
  free vault signatures that meet the threshold answer instantly (no
  board), otherwise the board collects per-owner and completion hands
  the combined signature back and closes — closing/cancelling rejects
  the dApp with 4001. Opening the board over a live message session
  settles that session first.
- dApp eth_sendTransaction starts a pending SafeTx and hands over to the
  board; the fee row names who pays (getSafeStatus executor — also used
  by the send review now); the dApp promise resolves with the execution
  hash via wallet:safe-executed and rejects on wallet:safe-discarded.
  Parking the board keeps the dApp waiting — its transaction IS pending.
- Gnosis-only guards on both paths (an unverifiable signature or a
  never-executable SafeTx beats a confusing failure later); safes are
  never auto-approved for transactions.
- Board openers accept the caller's fresh state, dropping the redundant
  re-fetch + free-sweep IPC on every dApp interaction.
- SafeMessage phone signatures get their own QR copy (context
  'safe-message').
- NEW E2E safe-dapp.spec.js: a real bzz:// dApp page connects the Safe
  through the webview provider bridge, personal_sign verifies via
  isValidSignature on the anvil Gnosis fork, and a send comes back as an
  execution hash with the balance moved.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Without an injected signaling override the broker probes the public
MQTT brokers with a real WebSocket — the unit suite silently depended
on broker reachability. The harness now injects a fixed relay.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Update colibri-stateless to version 2.0.0

safe-pending.json entries and live SafeMessage sessions are keyed by
wallet index. Deleting a Safe left them behind; since new wallet
indexes are assigned max+1, deleting the highest-index Safe let the
next account inherit — or be blocked by — the dead Safe's half-signed
SafeTx and session.

deleteDerivedWallet now discards the pending SafeTx entry and
force-drops the message session (unhooking its webContents listeners)
before the record is removed, via two dependency-light lazy requires.
The renderer's delete confirm warns when a waiting transaction and its
collected signatures are about to be discarded.

Fixes PR #160 review finding P2.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Main drops Safe message sessions on navigation, but the renderer's
handleProviderRequest still delivered the result (or error) of an
in-flight async request into whatever document currently occupies the
webview. Provider request ids restart per document, so a signature
completing after a navigation could satisfy a reused id in the
replacement page.

Mirror the document-generation guard from the Radicle provider (#145):
a per-webview generation in a WeakMap, bumped on did-navigate and
destroyed, captured when a request arrives, and re-checked before both
the success and error sends — stale responses are silently dropped.
The guard covers every async provider path, not just Safe signing.

Tests cover deferred Safe personal_sign completion after navigation
(result and error paths), destruction mid-request, and that a fresh
request from the replacement document still gets its response.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

This reverts commit 8ebd3f0.

Pin the new release together with the SHA256SUMS trust digest. This picks up the upstream phantom postage batch fixes while preserving reproducible binary downloads.

chore(build): update bundled Ant to v0.5.41